The global SQLite connection with check_same_thread=False can lead to subtle race conditions and locking issues under FastAPI's concurrent request handling. Consider creating a connection per request (or per thread) via a dependency, or using a connection pool pattern, and avoid sharing a single connection across all requests.

Hard-coding an absolute path to the SQLite database under /home/pi/... makes this service brittle outside that specific host; it will fail or write to an unexpected location in other environments. It would be more robust to take the DB path from an environment variable or configuration with a sensible default and ensure the directory exists at startup.

BaseModel is imported twice in the same module, once at the top and again near the /agent/complete endpoint, which is redundant and can be confusing. Removing the second import and grouping all imports at the top of the file will keep the module cleaner.

BaseModel is imported twice in the same module, once at the top and again near the /agent/complete endpoint, which is redundant and can be confusing. Removing the second import and grouping all imports at the top of the file will keep the module cleaner.

Avoid hard-coded Pi DB path

Hard-coding the database location to /home/pi/lucidia/lucidia.db makes the app fail to start anywhere that path doesn’t exist (e.g., local dev, CI, or Docker). In those environments sqlite3.connect raises “unable to open database file” because the parent directory is missing, so the whole FastAPI app crashes on import. Consider making the path configurable (env var) or resolving it relative to the repo so the committed lucidia.db can be used.

Useful? React with 👍 / 👎.